Games that switch resolution showed a black screen because the game ran as a child of the winhandler.exe desktop shell. Add winlauncher.exe to the container and launch the game through it so it runs as a decoupled top-level process; winhandler stays the shell and keeps handling input.

Pass /affinity to the launch helper so the game is pinned to the container's CPU set from process start, before the per-window affinity applies.

…ervice

The game now launches under winlauncher.exe as the wine desktop shell, while winhandler.exe runs as a separate input/process service, instead of the game running as a child of winhandler.exe.

The in-process Steam launcher received the game exe on argv[1], but the
desktop shell splits that argument on the first space, so a path like
C:\Program Files (x86)\... arrived as C:\Program. The launcher then never
matched the running game and never emitted a launch-complete marker, so the
preloader hung until the watchdog killed the session.

Pass the game exe to the launcher via the WN_STEAM_GAME_EXE environment
variable (argv[1] kept as fallback) so the shell launches a bare steam.exe
with no space-bearing argument to split.

The background input service now runs with a persistent idle child
(wn-idle.exe, staged into the container on boot) so its default file
manager never launches during shortcut or Steam sessions; container
boots without a target still open the file manager as before.
Bring-to-front raises the process window directly in the X server,
so it works for any requesting process; the guest-side request is
kept as a fallback.

…sses

Replace the prebuilt launcher and the idle helper with a single
WN-launcher.exe: it acts as the desktop shell and, with /idle, as the
input service's keep-alive child.

The shell now starts winhandler as its own child so the service shares
the game's virtual desktop. Previously winhandler ran as a separate
top-level process on the default desktop, so its input injection,
process spawning and bring-to-front never reached the game; relative
mouse, task-manager 'new task' and bring-to-front now work. This also
leaves a single launcher stub in the session instead of two.

The task manager refuses to end required system processes so the
session can no longer be torn down by ending its own plumbing.

WN-launcher runs the game and input service in kill-on-close jobs and force-ends a windowless leftover, so exiting the game tears down the whole tree (game, its popups, winhandler) and returns to the app instead of black-screening.

Task-manager bring-to-front resolves the window HWND, focuses it, and matches every WM_CLASS token, so it raises reliably without emptying the process list. close-kill escalates to SIGKILL when a closed window's process ignores SIGTERM.